The present invention generally relates to a rental system and method. More specifically, the present invention relates to a software rental system and method for renting software.
With few exceptions, most computer programs are instantiations of intellectual property and execute upon demand after installation. Normally, one can build and install an inexpensive copy of a computer program by little more than simply executing a copy command. A physical asset such as an automobile, on the other hand, cannot be easily copied. As a result, it is much easier to provide rental of physical assets than rental of computer programs. In the case of a physical asset, the renter first pays a rental fee, and then physically takes possession of the asset. At the conclusion of the rental period, the renter returns the physical asset to the owner. In the case of software, on the other hand, it makes little sense for the customer to return the program to the owner because one cannot guarantee that the customer refrained from sequestering his or her own backup copy. In the absence of adequate security measures, a customer acting in the role of an attacker could potentially rent the software for a short period of time and, subsequently, use the sequestered backup without paying further rental fees.
In the present invention, software rental as a computer system and method that securely stores rental (usage) records are defined. For example, consider the time-of-use rental metric. If the customer executes the rented software for one hour on the first day and for two hours on the second day, then, the secured audit trails show one hour at the end of the first day and three hours at the end of the second day. Secure software implies that a customer cannot defeat system security by purging, replacing, or modifying audit trails. Normally, the software continually monitors the audit trails to determine when a threshold is exceeded. So, if the example software has a five hour threshold, then the customer may execute the software for two more hours and then the software stops. Another example threshold is the total amount of times that the software may execute.
Some rental mechanisms that have all the properties listed above currently exist, e.g. Dongles (See Hardlock API, Manual Implementation of Hardlock Software Protecting Systems, High-Level API Version 3 Application Programming Interface, FAST Software Security-Group, FAST Document: High-Level API, Revision 4.00e, Mar. 1, 1996). Dongles have non-volatile memory which may be protected by passwords. This password protected memory may potentially be used for software rental. A characteristic of this rental mechanism is that it requires the assistance of a secured rental device, e.g. a Dongle. The secured rental device contains Secured Updateable Storage Locations SUSLs) that record information related to usage of the rented software. Each SUSL has the property that the SUSL resides on a secured device and provides protection against attack. Normally, at least one SUSL for each unit of rented software is required. For example, if a customer rents a word processor, a spread sheet, and a game, then the rental device(s) must provide at least three SUSLs. These SUSLs are relatively expensive and difficult to administer when compared to other storage on the customer's machine, e.g. memory or disk space.
Software rental, furthermore, significantly differs from a subscription to a network service. For example, suppose a software vendor provides a server to which customers connect via their software clients. During the period of the connection, the server audits usage records, e.g. connect time. The vendor assesses charges based upon the information recorded in the server's audit trail. This client-server example differs from the present invention because the present invention does not necessarily require an on-line presence by the software vendor. Rather, after obtaining permission to use the rented software, the customer executes the software without any required network connections. Furthermore, the subscription service does not prevent the customer from caching frequently used items.
An overview on asymmetric cryptography, for example, on the RSA scheme, and probabilistic encryption, for example, the Blum-Goldwasser probabilistic public-key encryption scheme can be found in A. Menezes et al., Handbook of Applied Cryptography, CRC Press, Inc. 1997, pp. 22-23, 224-233, 250-259, 308-311, 405-424, 433-438, 572-577.
An overview of different probabilistic proof schemes, for example, zero-knowledge proof schemes (e.g. Feige-Fiat-Shamir scheme; Guillou-Quisquater scheme; Blum-Feldmann-Micali scheme; Brassard scheme; Crepau scheme; etc.) or witness hiding proof schemes (e.g. Feige-Shamir scheme etc.) can be found in Menezes et al. supra.
An overview of digital signature schemes (e.g. Rivest-Shamir-Adelman, etc.) and a formal mathematical definition of digital signatures can also be found in Menezes et al. supra.
An example of a message digest function (otherwise known as a one-way hash function) is MDS and is described in R. Rivest, The MD5Message-Digest Algorithm, RFC 1321, April 1992. It is computationally infeasible or very difficult to compute the inverse of a message digest.
In P. Fenstermacher et al., "Cryptographic Randomness from Air Turbulence in Disk Drives," Advances in Cryptology: Crypto '94, 1994 Springer Verlag, pp. 114-120, cryptographic randomness from air turbulence in disk drives is described.
The Chi-Square Test, the Kolmogorov-Smirnov Test, and the Serial Correlation Test are described in D. Knuth, The Art of Computer Programming, Vol. 2, Seminumerical Algorithms, Addison-Wesley Publishing Co., 2.sub.2 nd Edition, 1981, pp. 38-73.
An asymmetric cryptographic mechanism includes public keying material and corresponding private keying material. It is computationally infeasible to compute the private keying material when given no more information than the corresponding public keying material. In the present invention, asymmetric cryptography is used in interactions between two parties, A and B. A proves to B that A has access to private keying material and B validates the proof. A does not disclose the private keying material to B.
A digital signature is an electronic analog of a handwritten signature. A digital signature proof involves at least two parties, A and B. After posting his or her public keying material to a public location, A encrypts a message using the private keying material. Since anyone may access the public keying material, there is no message secrecy. However, since A is the only customer with access to the private keying material, no one else can "forge A's signature" by performing the encryption. Anyone may validate A's signature using the public keying material--simply decrypt using A's public keying material.
An asymmetric confidentiality proof involves at least two parties, A and B. A possesses private keying material, and B has no access to A's private keying material unless B discloses the private keying material itself (which B should not do). At the beginning, A and B have no shared secret. During the method, a shared secret becomes known to A and B.
In all asymmetric cryptographic schemes, each customer may post his or her public keying material to a publicly accessed directory without compromising the corresponding private keying material. The customer usually should guard his or her private keying material as a close secret; otherwise, the cryptographic system may not guarantee correctness (secrecy). The best known mechanism for protecting one's private keying material is through the use of a smart card. In this case, the smart card is a device with no interface for releasing private keying material (in a non-cryptographically protected form). All cryptographic operations that directly reference the private keying material are performed on the smart card itself. As a result, no one can discover the contents of the private keying material stored on a smart card.
Although smart cards provide the best protection, social factors of electronic commerce may provide a role in ensuring private keying material protection. One of the significant difficulties associated with asymmetric encryption services is authentication. For example, if A posts his or her public keying material to a public directory, then how does B assess validity? That is, a pirate may attempt to masquerade as A but post the pirate's keying material. Some commercial organizations provide solutions to this problem by acting as Certification Authorities (CA). For, often times, a fee, the CA solicits identifying material from potential customers, such as a driver's license or passport. After validating the identifying material, the CA posts the customer's public keying material to a public directory, and the CA signs a certificate(using a digital signature with the CA's private key) that holds the customer's public keying material. Standardized services, for example, X.500, may be adopted to help facilitate the use of directories that contain public keying material.
Once a customer posts his or her public keying material to the CA, the customer will probably make an extensive effort to protect his or her private keying material. For some asymmetric keys, if the customer's private keying material were to become unknowingly compromised, then the customer would have cause for significant concern. For example, in the case of RSA keys that can also be used for digital signatures, networked vendors could potentially authorize electronic commerce transactions.
The present invention provides a system and method to create a cryptographically secure software rental system and overcomes the deficiencies of other known systems and methods.